(レポート) Developers Summit 2015 Autumn S-1:データを巡るテクノロジーの冒険 #devsumi

今日は目黒雅叙園で開催された、Developers Summit 2015 Autumnに参加してきました！

今回のデブサミはデータ関連テクノロジーにフォーカス。ビッグデータや大量トラフィック処理技術の最前線の話が聞けるということで、大変楽しみにしていました。

本記事はDevelopers Summit 2015 Autumnの最初のセッション、「データを巡るテクノロジーの冒険」のレポートです。本セッションは3名のスピーカーが3つの観点で、データ関連テクノロジーについてお話し頂きました。

レポート

Data-Driven Development Era and Its Technologies by トレジャーデータ株式会社 田籠 聡氏

・現在のデータ処理を行うとしたときにどんな問題があるのか、何をしなくてはならないのかの話 ・データにまつわる技術には何があるか？ ・データの収集 ・データの保存 ・データの処理 ・処理した結果の可視化 ・よく問題になるのはプロセッシング、処理の部分 ・プロセッシングだけがあってはダメ、収集、保存、可視化の部分が必要

・データ解析の流れ ・データソースから収集、保存、処理、可視化、そして必要な人に渡す

・データ処理をどこでやるか？ ・自分たちで一から作るのか ・様々なサービスを使うのか ・フルマネージドなサービス ・Google BigQueryとDataFlow ・TDのサービス ・セルフマネージド ・Amazon EMRとRedshift ・Google Cloud Dataproc ・自分たちの環境に自分たちで作る、オンプレミス環境 ・フルマネージドは手間がかからないがお金がかかる ・運用負荷がほとんど無い ・セルフマネージドはフルマネージドより安い ・性能出すためのチューニングは自分たちでやる必要がある ・オンプレミスな構成に比べれば手間が少ない ・自分たちで作る場合 ・ミドルウェアの運用が必要、運用コストが高い

サービスを使え ・解析に注力したいのであってサービス自体に注力したいのでは無い人が多いだろう ・データを解析した結果の知見が重要、運用は重要ではない ・なのでサービスを使っていきましょう

・Why should we use services? ・多くは分散処理、結構厄介、ダウンタイムなしでアップグレードするのはかなり大変 ・スモールスタートがやりにくい、最初から数台構成 ・分散処理を専門的に扱えるエンジニアは多く無い ・デーアドリブンの開発は、まずデータを集めて保存するところから始めなくてはならない ・データを集めて保存を自分たちで考え始めてしまうと、スタートダッシュが遅くなってしまう

・どうやってソフトウェアやサービスを選ぶのか ・何をやりたいのかが決まれば自動的に何を使うべきかが決まる ・データ処理の仕組みは基本的に分散処理 ・技術的な課題を解決するためにいろんな種類のサービスがある ・データの特性と何がしたいかがわかれば、ほとんどの場合1つか2つの選択肢が出てくる ・自分たちがまず何をやりたいか、を考えるのが重要 ・なんでもできる、という謳い文句のサービスがあるがそんなわけない、銀の弾丸は無い

・なにをやるのか、じゃあどうするのか ・何が欲しいのか？レポートなのか、分析なのか、レコメンデーションの仕組みなのか... ・最終的に欲しいアウトプットを考える ・どういうタイプのデータを処理したいのか？ ・ストレージ上にある巨大なデータか？過去のログファイルとか。 ・今現在流れてくるデータがあるのか？IoTセンサーデータやシスログ... ・どうやってデータが欲しいのか？CSVなのかグラフなのかDBなのか。 ・それぞれのサービスで対応しているもの、していないものが分かれる ・どんなサービスやソフトウェアがあるか ・バッチ処理のケース、素早く検索をしたいケース、データがストリームのケース、によって分かれる ・データ分析は全体の流れの中でごく一部、それ以外も必要 ・データの収集 ・データドリブンの開発はデータがないと何もできない ・どうやって集めるのか？ ・バッチでどこかに固まってるものをガバッと集める。Sqoop、embulk ・ストリームデータ。flume、logstash、fluentdなど ・fluentdの商用サポートサービスが始まる！今日！SRA OSSが提供 ・(参考:SRA OSSとトレジャーデータがログ収集基盤ソフトウェア Fluentd で協業、「Fluentdエンタープライズサポートサービス」を開始)

・他の重要なトピック ・ストレージ、ビジュアライズ、分散キュー ・ストレージ→安全に、処理できる形で保存しておく必要がある。そのコストパフォーマンスとパフォーマンスの両方が要求される。 ・ビジュアライズ→商用のソフトウェアやサービスがよく使われる、Tableauとか ・分散キュー→Apache KafkaやAmazon Kinesisが有名、次々に流れてくるデータの増減に合わせて蓄積するもの

・いろんな選択肢があるが用途やデータ、処理の特性によって何を選べばいいのかが変わる ・どういう特性があって何に向いているのかを知っておいてほしい ・データ処理を扱うときの苦労を減らしてくれる ・ただし、それにとらわれてはいけない。最終的に求められるものはデータの解析であってツールやサービスではない。これが一番重要なこと。

楽しい創作活動を加速する加速するトラフィック処理での工夫と技と頼れる仲間 by ピクシブ株式会社 小芝 敏明氏

・pixivは創作活動の場を提供する会社

・陣容とシステムからみたpixiv ・イラストコミュニケーションサイト ・システム的な側面。一般的なWebアプリケーションシステム。 ・特徴として、画像クラスタがある ・陣容。社員数が約100名。エンジニアは開発とインフラ。インフラが6名、開発が60名。 ・世界中で1500万ユーザーが利用している。

・pixiv3大トラフィックでデータ活用術 ・どういうところでトラフィックが起きて、データがたまっているのか？ ・画像トラフィック、広告インプレッション、ユーザアクティビティ ・画像トラフィック ・1日で26000作品の投稿が行われており、作品に対する閲覧がある ・下りのトラフィックがユーザー数に合わせて増加している。最大で18Gbps ・データセンターにたくさんの回線を引いている ・自前の画像配信クラスタ、オリジンとキャッシュクラスタ、サムネイルサーバ ・クラウド化は現在では考えていない、なぜならコストメリットが合わない ・今の仕組みは長年やってきており、事業とコストマッチしているから ・使われている技術はOSSで公開、サムネイルサーバも公開している(go-thumber) ・速度もクオリティも確実なものが出せるものを自前で作り込んでいる ・広告インプレッション ・自社に広告配信システムを持っている ・自社メディアからの広告リストを受けて配信する仕組み ・1ページに含まれる複数の広告を全て自社広告配信システムから配信している ・fluentdをアプリケーション制御として使用、管理サーバが落ちたとしてもfluentdのリトライですぐに復旧できる ・アド周りの分析はこれから頑張るところ、今はユーザーが楽しんでもらえるところにフォーカスしている ・fluentdを挟むことで今後のシステム拡張が容易 ・ユーザアクティビティ ・作品の投稿、人に対するフォローやマイピク、作品に対する閲覧と評価、ブックマークに追加、タグ付け ・プレミアム会員向けのサービスでレポート機能がある、どのくらい見られているのか、どこから流入されたのか ・アクティビティの取り組みの仕組み、fluentdで各サーバ群を接続している ・テキストでできた中間ファイルをfluentd経由でBigQueryやKibanaに流し込んでいる ・柔軟性と拡張性の担保を重視して構成している ・アクセスログは自社データセンターに投げている。BigQueryを使っていないのはコストの問題

・今後の展望、pixivとデータとの付き合い方のロードマップ ・ぶっちゃけ無い、欲しくなったら繋ぎ、足りなくなったら増強し、次につなげていく ・実験しながら実運用に繋げていく ・創作活動にフォーカスしており、どうやったらユーザーさんが楽しめるか？を考えて、その結果をデータで繋ぎ、アクションに繋げていく ・データドリブンの開発はしていない、データは本質では無い。楽しいを追求するためにうまくデータと付き合っていく

・こういうサービスを支えているのは私たちメンバーの試行錯誤 ・pixivやサービスのあり方にこだわりがあり、様々な技術を持ったメンバーが作ってきた ・新しいメンバーが増えたらまた新しい仕組みを構築していくだろう

分散アプリケーションアーキテクチャ2015 by Kaizen Platform, Inc. 伊藤 直也氏

・大量トラフィックとデータ ・5,6年前まではLAMPでRDBにデータをガンガン入れていた ・処理しきれず大変な思いをしてきた ・大量のデータが入っているDBにバッチ処理したら、詰まって障害が起きるとか ・リアルタイムなデータ処理が大変

・昨今 ・バッチはHadoopやBigQueryなどが使えるようになってすごく楽 ・ストリームは力技で乗り切ってることが多い ・kaizenではABテストのサーバを運営している、ユーザーから1アクセスごとにストリームのデータが流れ込んでくる ・必然的に分散システムになっていく ・今はRailsなどを使って疎結合にしている、今後どうなるんだろう？

・Real-time Web ・リアルタイムっぽい動きをするサービス、Twitter、Facebook、Google検索など ・データを受け取って、画面に反映するサービス ・リアルタイムWebと言われて5年くらい経って、今はあんまり言われなくなった ・廃れたのではなく実現されて当たり前になったから ・でもまだ力技で作ってる

・リアルタイムWebの問題を解決しようとしているもの ・TypesafeのReactive Platform ・データがストリームで流れてくるものを体系的に書けるようにすることを目指している ・Reactive System、モダンなWebシステム ・Ractiveって最近聞くけどなんだろう？ ・Reactive Manifestoに書かれた要件、性質を満たすものをReactive Systemと呼んでいる

・Reactive Manifesto ・昨今の分散アプリケーションに求められている性質 ・メッセージ駆動で、エラスティックで、トラフィックがスパイクしても落ちない、リアルタイムを達成 ・message passing、ノンブロッキング、シェアードナッシング、疎結合で実現しよう、ということが描かれている

・Reactive Systemの実際 ・全てのコンポーネントが非同期インターフェースを持っている ・非同期インターフェースをReactive Streamsに従って繋げる ・大量のデータを流し込まれるとノンブロッキングなので壊れてしまう、それを制御するもの ・Pub/Subで流量を先に教えておくことで溢れるようなデータを流し込まないように ・データ伝送路をストリームとして扱うように抽象化したモデル

・考察 ・リアクティブかどうかはさておいて ・リアルタイムなアプリケーションは体系だった標準的なミドルウェアやAPIがなく、力技だった ・通しでノンブロッキング前提、非同期ストリームな仕組みを、体系的に示したもの ・AkkaはErlang/OTPのインスパイア

・Microservice ・大規模なシステムを分割して疎結合する手法 ・Reactive Systemと関係がある。同期的なシステムを非同期で繋ぐとMicroserviceぽくなる

・Microserviceの実際 ・Microserviceという言葉には通信手段の定義は無い ・そもそも現象に名前を付けただけで仕様ではない ・プログラミングモデルの課題 ・ごった煮のシステム、それぞれごとにインターフェースが違う、実装コストが跳ね上がる ・インフラ ・リトライや障害検知など、いろいろなことを考えなくてはいけなくなる ・コンポーネントごとに作り込んでいくとか結構大変

・Microserviceのフレームワーク ・プログラミングモデルとインフラを提供する実装 ・Finagle(Twitter) ・Colossus(Tumbler) ・Finagle ・Twitterが作ったもの ・TwitterはもともとRailsで作っていたが、スケールしなくなったのでScalaで作り直した ・それぞれのAPIをつなぐものとして作ったのがFlagle ・Your Server as a Function、全ては関数として抽象化できる。関数を使えば裏側はフレームワークに任せられる ・Finagleを使うとServiceやFilterなどを抽象化できる。プログラマはRPCを関数呼び出しとして書ける ・流量制限などはFinagleでやってくれる ・Microserviceが散らばることの複雑性を解消できる

・わかること ・従来の方法では分散システムをスマートに扱うのが難しい ・疎結合に伴って抽象化が課題になっている ・実装を伴った新しいアプローチ、Ractive PlatformとFinagleを紹介した ・系全体を見て、どういうフレームワークで抽象化できるのか、この辺がトレンド

・傾向 ・分散アーキテクチャを体系的にアプローチするようになっている ・力技から系全体を見るフェーズに